Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix version logic when bumping major version #38593

Merged
merged 2 commits into from
Feb 8, 2019
Merged

Fix version logic when bumping major version #38593

merged 2 commits into from
Feb 8, 2019

Conversation

tvernum
Copy link
Contributor

@tvernum tvernum commented Feb 8, 2019

When we are preparing to release a major version the rules around
"unreleased" versions and branches get a bit more complex.

This change implements the following rules:

  • If the tip version on the previous major is a .0 (e.g. 6.7.0) then
    the tip of the minor before that (e.g. 6.6.1) must be unreleased.
    (This is because 6.7.0 would be "staged" in preparation for release,
    but 6.6.1 would be open for bug fixes on the release 6.6.x line)
    (in VersionCollection & VersionUtils)

  • The "major.x" branch (if it exists) will always point to the latest
    minor in that series. Anything that is not the latest minor, must
    therefore be on a the "major.minor" branch
    For example, if v7.1.0 exists then the "7.x" branch must be 7.1.0,
    and 7.0.0 must be on the "7.0" branch
    (in VersionCollection)

@tvernum
Fix version collection when bumping major
b775a61 
When we are preparing to release a major version the rules around
"unreleased" versions and branches get a bit more complex.

This change implements the following rules in VersionCollection:

- If the tip version on the previous major is a .0 (e.g. 6.7.0) then
  the tip of the minor before that (e.g. 6.6.1) must be unreleased.
  (This is because 6.7.0 would be "staged" in preparation for release,
  but 6.6.1 would be open for bug fixes on the release 6.6.x line)

- The "major.x" branch (if it exists) will always point to the latest
  minor in that series. Anything that is not the latest minor, must
  therefore be on a the "major.minor" branch
  For example, if v7.1.0 exists then the "7.x" branch must be 7.1.0,
  and 7.0.0 must be on the "7.0" branch
@tvernum
The previous major can have 2 unreleased versions
3f3a398 
If we have versions ... v6.6.0 , v6.6.1 , v6.7.0 , v7.0.0 , v7.1.0
then only v6.6.0 is actually released, the others are all under
maintenance/development.
@tvernum tvernum requested review from alpar-t and jasontedor February 8, 2019 02:26
@tvernum tvernum added the v8.0.0 label Feb 8, 2019
@tvernum
Copy link
Contributor Author

tvernum commented Feb 8, 2019

I've targeted this to 7.x because that's where the behaviour is needed (it's currently causing the BWC tests to fail), but I will need to backport it to 7.0 and forward port it to master.

@tvernum
Copy link
Contributor Author

tvernum commented Feb 8, 2019

elasticsearch-ci/default-distro

02:37:01    > Throwable #1: org.elasticsearch.client.ResponseException: method [PUT], host [http://[::1]:39656], URI [/_template/test_template?include_type_name=true], status line [HTTP/1.1 400 Bad Request]
02:37:01    > {"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"request [/_template/test_template] contains unrecognized parameter: [include_type_name]"}],"type":"illegal_argument_exception","reason":"request [/_template/test_template] contains unrecognized parameter: [include_type_name]"},"status":400}
02:37:01    > 	at __randomizedtesting.SeedInfo.seed([B7F689F194456ED5:889363085EF869AA]:0)
02:37:01    > 	at org.elasticsearch.client.RestClient.convertResponse(RestClient.java:260)
02:37:01    > 	at org.elasticsearch.client.RestClient.performRequest(RestClient.java:238)
02:37:01    > 	at org.elasticsearch.client.RestClient.performRequest(RestClient.java:212)
02:37:01    > 	at org.elasticsearch.upgrades.FullClusterRestartIT.testSnapshotRestore(FullClusterRestartIT.java:918)
02:37:01    > 	at java.lang.Thread.run(Thread.java:748)

./gradlew :qa:full-cluster-restart:v6.6.1#oldClusterTestRunner -Dtests.seed=B7F689F194456ED5 -Dtests.class=org.elasticsearch.upgrades.FullClusterRestartIT -Dtests.method="testSnapshotRestore" -Dtests.security.manager=true -Dtests.locale=es-US -Dtests.timezone=Canada/Pacific -Dtests.distribution=default -Dcompiler.java=11 -Druntime.java=8

This reproduces, but isn't related to this PR, so I will fix it in a separate change.

@elasticmachine run elasticsearch-ci/default-distro please.

@tvernum
Copy link
Contributor Author

tvernum commented Feb 8, 2019

BWC tests will keep failing until #38594 is merged.

@tvernum tvernum mentioned this pull request Feb 8, 2019
Merged
alpar-t
alpar-t approved these changes Feb 8, 2019
View reviewed changes
Copy link
Contributor

@alpar-t alpar-t left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM thanks for the fix !

@tvernum tvernum merged commit 84483b2 into elastic:7.x Feb 8, 2019
tvernum added a commit that referenced this pull request Feb 8, 2019
@tvernum @jasontedor
Fix version logic when bumping major version (#38595)
558b454 
When we are preparing to release a major version the rules around
"unreleased" versions and branches get a bit more complex.

This change implements the following rules:

- If the tip version on the previous major is a .0 (e.g. 6.7.0) then
  the tip of the minor before that (e.g. 6.6.1) must be unreleased.
  (This is because 6.7.0 would be "staged" in preparation for release,
  but 6.6.1 would be open for bug fixes on the release 6.6.x line)
  (in VersionCollection & VersionUtils)

- The "major.x" branch (if it exists) will always point to the latest
  minor in that series. Anything that is not the latest minor, must
  therefore be on a the "major.minor" branch
  For example, if v7.1.0 exists then the "7.x" branch must be 7.1.0,
  and 7.0.0 must be on the "7.0" branch
  (in VersionCollection)

- Special logic so that the 7.0.0 build knows that we do not plan
   to have any 6.x releases after the 6.7 series
 
Backport of: #38593 
Partial Backport of: #38513

Co-authored-by: Jason Tedor <[email protected]>
jasontedor added a commit to jasontedor/elasticsearch that referenced this pull request Feb 8, 2019
@jasontedor
Merge branch '7.x' into docker-from-artifacts-7.x
ec40b57 
* 7.x:
  Make qa/full-cluster-restart tests pass. By fixing a helper method and (elastic#38604)
  Mute failing WatchStatusIntegrationTests (elastic#38621)
  Mute failing  ApiKeyIntegTests (elastic#38614)
  [DOCS] Add warning about bypassing ML PUT APIs (elastic#38605)
  Mute RetentionLeastIT.testRetentionLeasesSyncOnRecovery on 7x (elastic#38597)
  Only "include_type_name" if running on >= 7 (elastic#38594)
  Fix version logic when bumping major version (elastic#38593)
alpar-t added a commit to alpar-t/elasticsearch that referenced this pull request Mar 6, 2019
@alpar-t
Forward port bwc version fix from 7.x
994fe17 
While working on a backport I realized that elastic#38593 was merged in `7.x`
and missing in master.
We need this or it will cause trouble again when we bump majors next
time.
@alpar-t alpar-t mentioned this pull request Mar 6, 2019
Closed
@mark-vieira mark-vieira added the Team:Delivery Meta label for Delivery team label Nov 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@alpar-t alpar-t alpar-t approved these changes

@jasontedor jasontedor Awaiting requested review from jasontedor

Assignees
No one assigned
Labels
:Delivery/Build Build or test infrastructure >non-issue Team:Delivery Meta label for Delivery team v7.0.0-beta1 v7.2.0 v8.0.0-alpha1
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@tvernum @alpar-t @jakelandis @mark-vieira @jimczi